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I. Real Party in Interest 

The real party in interest is Open Invention Network, Inc., the assignee of record. 

II. Related Appeals and Interferences 

A prior appeal was decided in this case, Appeal No. 2006-1639, decided August 
31 , 2006. (R 2) Reconsideration was denied May 21 , 2007. (R 22) A Petition for a 
second rehearing was dismissed as moot on September 17, 2007. (R 30) There are no 
other known appeals or interferences relating to this case. 

III. Jurisdictional Statement 

The Board has jurisdiction under 35 U.S.C. 134(a). The Examiner mailed a non- 
final rejection on October 9, 2008 (R 36), setting a three-month shortened statutory 
period for response. The time for responding to the rejection was set to expire on 
January 9, 2009. Rule 134. More than two office actions have been issued, so an 
appeal can be taken from a non-final office action. A notice of appeal was filed on 
December 9, 2008. The time for filing an appeal brief is two months after the filing of a 
notice of appeal. Bd.R. 41 .37(c), which will expire on February 9, 2009. This brief is 
being filed on December 16, 2008. 

IV. Status Of Claims 

Claims 1-15 and 61-74 are pending in this case and all have been rejected. 

IV-A. Status Of Amendments 

No amendments have been filed subsequent to the most recent office action. 

V. Summary of Claimed Subject Matter 

There are three independent claims related to an interface for transactions and 
for a method for programming that applies the method. The claimed embodiments are 
useful for transactions among nodes in a network (FIG. 1 , R 60) including a plurality of 
nodes that execute processes involved in the transactions (FIGS. 3, 7, 1 1 , R 62, 66, 70) 
the interface being stored in a computer readable medium. For instance, a Web service 
in an electronic commerce network can use the interface described to compose, send 
and receive XML-formatted electronic commerce documents such as a purchase order 
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(FIG. 8, ref. 811) submitted to and a PO acknowledgement received from a PO- 
receiving web service. 

The interface claimed is stored in memory accessible by at least one node in the 
network. It includes a machine-readable specification of an interface to transaction 
processes [claim 1] or operations [claim 73] (FIG. 2, R 61). The specification includes 
interpretation information providing a definition of an input document (refs. 21 1 , 213- 
218), and a definition of an output document (refs 212, 219-224). The definitions of the 
input and output documents comprise respective descriptions of sets of storage units 
and logical structures for the sets of storage units, for instance, XML documents. (R 79- 
80) 

Claim 15 is suggested as representative of the group that includes claim 1. It 
specifies a particular embodiment, wherein the definitions of the input and output 
documents use document type definitions (DTDs) compliant with a standard Extensible 
Markup Language XML. (FIG. 15, R 74; R 80) 

Dependent claim 5 specifies that the machine readable specification be in a 
document that complies with a definition of an interface document, for instance, an XML 
document. (R 80, line 1) A sample embodiment, as an XML fragment, appears on page 
45 of the Application. (R 1 20) 

Dependent claim 7 further requires the machine readable specification to include 
a reference to a specification of a particular transaction, which the Application 
exemplifies as a pointer. (R 82, line 18) 

Dependent claim 13 further includes a repository and specifies that at least one 
of the input and output documents be defined by reference to a document type stored in 
the repository. (R 82, line 18) 

Dependent claim 14 requires that the repository include, in addition to the 
document type definitions in claim 13, a document type for identifying participant 
processes in the network. (R 84, line 12) 

Dependent claim 1 6 requires that the machine readable specification of claim 1 
qualify as an XML document, defined by a DTD. (R 120) 

Another embodiment, independent claim 61 , is a method for programming a 
commercial transaction in a network. This method includes defining a machine-readable 
definition of an input document (FIG. 2, R 61 ) for a node in the network (FIGS. 3, 7, 1 1 , 
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R 62, 66, 70) including resources to execute a process in the transaction, and a 
machine-readable definition of an output document (FIG. 2) for the node. The definitions 
of the input and output documents include respective descriptions of sets of storage 
units and logical structures for the sets of storage units. The method includes providing 
interpretation information for the logical structures to the node. 

Dependent claim 72 further requires of the method for programming, providing a 
parser that handles input document definitions and generates event signals and an 
event listener that responds to the event signals. (FIG. 5, refs. 500, 503, 504A, R 64) 

VI. Issues/Rejections To Be Reviewed On Appeal 

The issues are arranged by subject: removal of McKendrick's brief article as 
reference; why the claims are allowable over McKendrick and the XML 1 .0 
Recommendation; and overcoming the section 112 rejections of newly added claims 73- 
74. 

Whether the Examiner erred in rejecting each of the pending claims 1-16 and 61- 
74 under 35 U.S.C. § 103(a) because the undisputed evidence establishes actual 
reduction to practice of the claimed technology before the September, 1998 publication 
of McKendrick's brief article? 

Whether the Examiner erred in rejecting claims 1, 2, 4, 8-12, 15, 64, 73 & 74; 5-6 
& 65; 7; 1 3; 1 4; 1 6; 61 & 66-71 ; and 72 under Section 1 03(a), because one of ordinary 
skill in the art, circa 1998, would not have found McKendrick's brief article in 
combination with the newly published XML 1 .0 Recommendation to provide a written 
description or enabling disclosure of the claimed technology? 

Whether the Examiner erred in rejecting claims 73-74 under Section 112, 
because "operations" are referred to in the original specification dozens of times and 
one of ordinary skill in the art, after reading the specification, would understand 
operations to have a very similar meaning to transaction processes? 

VII. Grouping Of Claims 

Due to the Board's decision on the first appeal, which suggested showing that 
each dependent claim (R 10) was reduced to practice before the critical date, the 
dependent claims are individually addressed. Only claims 1 & 73 and 2 & 74 grouped 
together for purposes of removing McKendrick as a reference. 
{ooi43569.doc } Page 3 
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In response to the Section 103 rejections, Applicants group the claims as: 1, 2, 4, 
8-1 2, 1 5, 64, 73 & 74; 5-6 & 65; 7; 1 3; 1 4; 1 6; 61 & 66-71 ; and 72. Independent claims 1 
and 73 are grouped together, along with various dependent claims. Independent claim 
61 is grouped with various dependent clams. Six groups of dependent claims are 
argued separately, to give context to the independent claims and avoid any "broadest 
reasonable interpretation" that would be inconsistent with the specification or the 
dependent claims. 

Applicants group claims 73-74 for response to the Section 112 rejections, 
because the Examiner rejected claim 74 solely on the basis that it depended from claim 
73. 

VIII. Argument 

A. Statement of Facts 

1 . Introductory Statement Regarding the General Area of Technology 

This application is 10 years old, as old as the use of XML for e-commerce. The 
Examiner, reviewing the evidence of record, concluded that the claimed technology was 
conceived of in 1997. (R 57) The industry organization W3C published the XML 1 .0 
"Recommendation" on February 10, 1998 (R 194), following committee work and draft 
recommendations. This application was filed on October 16, 1998. (R 59) 

This technology relates to what has come to be called Web services. The 
claimed interface definition technology is particularly useful for the so called document- 
style interface to Web services. 

In 1998, VEO's document-style interface rivaled Microsoft's remote procedure 
call or RPC interface for use in e-commerce. Over 5-10 years, the document-style 
interface ended up dominating some segments of e-commerce. It took several years for 
standards to be formulated for document-style interface definitions and for use of 
document-style interfaces. It took longer for some of the major software vendors to 
abandon RPC as their default and preferred interface to e-commerce interactions. 

Related to the claimed technology, but not subject to patent protection and 
dedicated to royalty-free public use, is a collection of business document forms called 
the "common business library", abbreviated CBL. (R 175). See, www.xCBL.org. 

The claimed interface definition technology does not depend on CBL or 

necessarily even on XML. Conversely, the CBL documents can be used for e- 
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commerce processes that do not incorporate the claimed interface specifications. 
(Decls. § 10, R 389). CBL documents could be used by processes that use remote 
procedure call interfaces, instead of document-style interfaces. 

2. Facts Related to the Application 

Applicants filed three applications on October 16, 1998 that have overlapping 
specifications. Three patents have issued to this family, US Patent Nos. 6,542,912, 
6,226,675, and 6,1 25,391 . One of the three patents issued from a divisional of this 
application. This application and application number 09/173,854 remain pending. 

The applications originally were assigned to a start up, VEO Systems, which 
merged with Commerce One. Commerce One had a very successful initial public 
offering, but faltered and filed for bankruptcy in 2004. JGR Acquisition, Inc. acquired 
substantially all of Commerce One's portfolio in a highly publicized bankruptcy auction. 
A little more than a year later, it assigned the portfolio to Open Invention Network, Inc., 
which is the current assignee and real party in interest. Open Invention Network gives 
away "free" licenses to this portfolio, on terms that support open software development 
in the Linux environment. The terms of the royalty-free license can be found on the 
website at www.openinventionnetwork.com/patents.php, (not of record). 

The VEO Systems team was very active in teaching the user community about 
the document-style interface to Web services and promoting its adoption. Their 
evangelism included speaking at conferences on the emerging technology, writing 
papers and participating in industry committees. 

3. Facts Related to the Prior Appeal 

Most of the claims in this application were subject to a prior appeal and have not 
been amended since then. In response to new issues raised by the Board, Applicants 
submitted evidence during appeal, which the Board directed should be considered by 
the Examiner. This second appeal includes new declarations and new exhibits. 

The first appeal was decided adversely to applicants on August 31 , 2006. (R 2) 
The Board's rationale adopted neither the Examiner's reasons that were appealed nor 
the Examiner's arguments on appeal. Accordingly, Applicants filed request for 
reconsideration with responsive evidence. The Board's decision was again the adverse 
to Applicants. (R 22) 
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Applicants petitioned for a second reconsideration, in part asking that the Board 
expressly remand the case to the Examiner for consideration of new issues raised by 
the Board's decisions and the new evidence. The petition for a second reconsideration 
was denied by the Chief Administrative Judge as moot (R 30), due to filing of an RCE 
(R 233) at the same time as the petition. 

4. Facts Related to General Errors in Examination 

The facts in this section relate primarily to evidence that the Examiner did not 
dispute, criticize or comment on in any way. 

Subsequent to the RCE, Applicants submitted five new declarations from 
inventors and a non-inventor (R 326-401 ), with hundreds of pages of exhibits. Among 
the corroborating exhibits are data structures, source code and memoranda. 
Proceeding with declarations by four out of five inventors was approved by the Office of 
Petitions. (R 323) 

a. Undisputed Facts Regarding Actual Reduction to Practice of 
the Claimed Technology Before January 21, 1998, Eight 
Months Before Publication of McKendrick Reference. 

In Section 19 of the new declarations, 5 1/2 pages of extensively corroborated 
testimony (R 395-400) establish actual reduction to practice of the claimed subject 
matter before January 21 , 1998, months before McKendrick's brief article was 
published. This evidence is undisputed, as the Examiner's non-final office action mailed 
October 9, 2008 completely ignores section 19 of the declarations. (R 18-21) The 
Examiner does not criticize or dispute either the facts established in section 19 or the 
sufficiency of the corroborating documents. 

Moreover, sections 13-16 of the declarations (R 390-394) establish actual 
reduction to practice of the claimed technology by reference to the imdesc.xml data 
structure. (R 392-393) It is undisputed that the imdesc.xml data structure (Exhibit G , 
R 578) embodies limitations of the claims. The Examiner's non-final office action 
October 9, 2008 completely ignores sections 13-16. (R 54-57) The data structure is 
dated January 2, 1998. (R 392) It was placed in memory, tested and proved to work for 
its intended purpose in advance of a customer demonstration scheduled for January 21 , 
1998. (R393) 
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The part of the imdesc.xml data structure that we quoted is only 23 lines long. 
(R 308, 578) It is short and elegant enough to be understood and logically tested by 
inspection. 

b. Undisputed Facts Regarding Actual Reduction to Practice of 
the Claim Technology on or Before July 25, 1998, Two Months 
Before Publication the McKendrick Reference. 

Applicants' declaration testimony (R 393-394) proves a public demonstration of 
interface definition technology at a conference on July 25, 1998. The data structure 
depicted in Exhibit I, slide 30 (R 678, 394) embodies limitations of the claims. The data 
structure was publicly disclosed in the context of a larger technology presentation. It is 
undisputed that the next slide in the presentation, slide 31 (R 679) disclosed that "CBL 
v1 .0" was in use before July 25, 1998, in demonstration applications including Project 
Seitai and GSA catalog interoperability. (See Decls. § 19, Claim 4, R 396) 

The Examiner's non-final office action mailed October 9, 2008 refers to slide 30 
as, "merely a PowerPoint document" (R 54), without any analysis of slide 30's 
evidentiary significance or the declaration testimony (R 393-394) that explains it. The 
Office Action ignores slide 31 . The presentation evidence that the Examiner ignored 
proves actual reduction to practice, including testing. It is entirely credible that the 
inventors tested their data structure and used it in demonstration projects before Dr. 
Robert Glushko disclosed as much at the International Workshop on Component-based 
Electronic Commerce, Haas School of Business, University of California, Berkeley. It is 
noteworthy that Dr. Glushko's work and scholarly presentations were regarded well 
enough for him to join the faculty of the Fischer Center for Information Technology and 
Marketplace Transformation, Haas School of Business, after he left Commerce One. 

The imdesc.xml data structure, dated January 2, 1998 (R 579), and the slide 30 
data structure, disclosed July 25, 1998 (R 678), are substantially similar to the data 
structure disclosed on page 45 of this application. (R 120; see Decls. §§14-17, R 392; 
see, also, Response, R 305) One of ordinary skill in the art would conclude, after 
comparing the cited data structure versions, that the inventors had created an 
embodiment on January 2, 1998 of the technology disclosed their patent application 10 
months later. 
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c. Undisputed Facts Regarding the Level of Ordinary Skill in the 
Art in September-October, 1998. 

The Examiner made no factual findings regarding the level of ordinary skill in the 
art and did not respond to Applicants' position on the issue. 

These inventors included lecturers and authors. Those of ordinary skill in the art 
looked to these inventors for technological leadership. The relevant timeframe is 
summer-fall, 1998, closely following publication of the XML 1.0 Recommendation in 
February 1998. (R 194) Some of the inventor's lectures from 1998 are exhibits. (Exhibits 
I & K, R 648, 686) Their subsequent writings (Exhibits B, M, O, V, R 41 1 , 71 8, 739, 
849), which were prepared for non-patent purposes, describe the course of their 
development efforts and their pioneering leadership in their field. 

On September 1 , 1998, the audience at a conference presentation by 
Dr. Glushko questioned whether XML was stable enough to be used with production 
software. (R 704) Dr. Glushko responded, "I sort of think XML is stable enough. ... XML 
is undergoing a lot of changes. There is a major effort coming down the road which is 
an XML schema language, which would let you describe more data typing and semantic 
information inside of the XML definition, and that will be really important for commerce. 
... [0]ur little working group we just started has Microsoft, Sun and Netscape in it 
because they recognize that XML will fail unless they all get along at some basic level." 

The only evidence of record regarding teaching the claimed technology to those 
of ordinary skill at any time in 1998 is evidence of the inventors' teachings. There is no 
evidence of record of a technical description with enabling details of the claimed 
technology during 1998 by anyone other than the team that included these inventors. 

d. Undisputed Facts Regarding How One of Ordinary Skill in the 
Art Would Have Understood the McKendrick Reference in 
September, 1998. 

It is undisputed that a Microsoft article dated April 3, 1998 contains the phrase 
that McKendrick quoted, in a section of the article entitled "Opportunities." (Exhibit Q, 
R 784) There is no other evidence of record regarding what McKendrick was reporting 
from Microsoft. The Examiner ignored Exhibit Q, which is projecting opportunities and 
does not include a written description or an enabling disclosure of the claimed 
technology. 
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The passage from McKendrick's brief article, on which the Examiner relies (R 39- 
40) for input and output documents, is only 53 words long. It reads, " 'Customer services 
are now migrating to Web sites from call centers and physical locations,' states a report 
from Microsoft Corp. 'And, because most of these business applications involve 
manipulation and transfer of data-such as purchase orders, invoices , customer 
information and appointments XML will allow a rich array of business applications to be 
implemented .' " (R 192) (underlining added). 

There has not been any express consideration by the Examiner of how 
McKendrick's words would have been understood by one of ordinary skill in the art, in 
September, 1998 (R 36-58), despite Applicants' urging. 

It is undisputed that Microsoft was advocating, at the time of McKendrick's article, 
that protocols be developed that would use XML for remote procedure calls. The 
evidence includes remarks at a conference in Europe in May, 1998 by a general 
manager of Microsoft (Exhibit R, R 791 ), a pair of articles from July, 1 998 reporting on 
Microsoft's XML-related activities (Exhibits S-T, R 802, 809) and a patent. (Exhibit U, 
R 812) The patent issued from an application filed on March 23, 1999, by a Microsoft 
partner that was working on XML-RPC. 

There is no evidence of record to suggest that those of ordinary skill in the art, 
familiar with Microsoft's teachings about XML-RPC in 1998-99, would have understood 
McKendrick's brief discussion of Microsoft's activity to describe or enable practice of the 
claimed interface definition technology. 

Both the imdesc.xml data structure (R 578) and the slide 30 data structure 

(R 677) provide and are accompanied by much more written description and enabling 

disclosure of the claimed technology than McKendrick's 53 words. (R 193) 

e. Undisputed Facts Regarding Actual Reduction to Practice of 
Subject Matter in Individual Claims. 

Applicants understand the Board's prior decision to suggest a claim-by-claim 

statement of facts regarding actual reduction to practice. (R 10). The facts that follow 

are taken from Section 19 of the declarations (R 395-400), with references to the 

Record added. These facts are undisputed because the Examiner ignored them. 

" Claim 1: In Exhibits G-l, both imdesc.xml (R 578, Slide 30, R 678) depict 

machine readable interface specifications. The imdesc.xml file typically is found in a file 
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directory on a machine readable storage media. The PowerPoint Slide 30 appears to 
have been taken from a computer file similar to imdesc.xml and pasted into the 
presentation. The archive for imdesc.xml and the PowerPoint presentation both were 
stored on machine readable storage media. Both data structures define an interface to a 
transaction process. The imdesc.xml defines an interface with several service 
"functions". Slide 30 defines multiple service "operations". In imdesc.xml, one of the 
input documents is an "order"; in Slide 30, there is a "po", which is short for purchase 
order. In both transaction interface definitions, an acknowledgement is sent, an "ack" in 
the earlier version and a "poack" in the later version. The input document definitions are 
referenced by "order.dtd", "invoiceo.dtd", "paynoteo.dtd", "po.dtd" and 
"request.track.dtd", which are data type definition (dtd) files. The output document 
definitions are referenced by "ack.dtd", "poack.dtd" and "response.track.dtd". The 
January 1998 demonstration scenario (Ex. F, R 390-391 , 570) makes it clear that these 
interface definitions were published to nodes on a network that might desire to invoke 
the functions for which interfaces were defined. The context of the slides and other 
remarks by Glushko, including ongoing demonstration projects, make it clear that this 
interface was hosted and accessible to a plurality of nodes on a network in the 
development environment from which it was borrowed for the PowerPoint presentation. 

" Claim 2: The data type specifications in the exemplary "order.dtd" (Exhibit E, 
R 476) include at least one logical structure. Similarly, slides 25-29 (Exhibit I, R 683- 
677) depict using logical structure building blocks to construct documents such as a 
purchase order (po.dtd). In general, a data type definition file (dtd) will include data type 
specifications for at least on logical data structure. 

" Claim 3: The data type specifications for the country field of the exemplary 
"order.dtd" (Exhibit E, R 476) include at least one data structure mapping predefined 
sets of storage units for a particular logical structure in the definitions to respective 
entries in a list. The country code field is supported by a list in "codes. mod" (the codes 
module), which is incorporated into addresso.mod which, in turn, is part of order.dtd. 
With a bit of tracing from imdesc.xml, one can see where the reusable lists were part of 
the system. Use of country codes in addresses is a feature of CBL that extended the 
XML recommendation -the XML recommendation uses codes for language 
identification and not for addresses. See, W3C Recommendation, Extensible Markup 
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Language (XML) 1.0, § 2.12 (Feb. 10, 1998) (R 206) accessed at 
http://www.w3.Org/TR/1998/REC-xml-19980210#dt-app. Turning to the July 25, 1998 
presentation, slides 27-28 (R 675-676) similarly illustrate use of country codes in a 
purchase order, defined by the file "po.dtd". 

" Claim 4: In Exhibit D (R 428), the ENTITY "command" and the related 
ELEMENTS support registering definitions of documents and services in a repository in 
memory accessible to at least one node. The definitions of documents and services 
include logical structures and interpretation information for logical structures. In Exhibit I, 
Slide 23 (R 671) depicts a service registration document in a registry accessible to 
discovery nodes on a network. Slide 31 (R 678) indicates that CBL was already in use 
for demonstration applications, Project Seitai and GSA catalog interoperability. We 
found it very useful to post our interface definitions for programmers to rely on during 
development, such as the imdesc.xml interface definition. 

" Claim 5: Looking through files from the ingram/01 directory, which are 
reproduced in Exhibit H (R 581), one finds the data type definition corresponding to the 
sample interface definition imdesc.xml. Beginning with imdesc.xml on page 32 of 66 
(R 613), one sees reference to "imarkdsc.dtd" in the DOCTYPE statement of line six. 
This data type definition appears on page 29 of 66 (R 610), and incorporates by 
reference the "isrvprim.mod" module that appears on page 54 of 66. (R 635) The 
isrvprim.mod defines elements of imdesc.xml, including service. name, 
service. location. pointer, and service/function. Thus, the sample "imdesc.xml" machine 
readable specification of Exhibit G (R 578) complies with the imarkdsc.dtd definition of 
an interface document including logical structures for storing identifiers (e.g., 
service. name and/or input doctype) and references to definitions (dtd's) of input and 
output documents. Similarly, in Exhibit I, slide 30 (R 678), identifiers of particular 
transactions appear as "Submit Order" and "Track Order." The references to definitions 
of the input and output documents are dtd file names. The "Loose Coupling" via Shared 
Document Definitions slide 22 (R 670) makes it clear that the definition in slide 30 is a 
document that complies with a dtd, as in the ingram/01 files. 

" Claim 6: Both the "imdesc.xml" Exhibit G (R 578)and the Slide 30 in Exhibit I 
(R 678) specify one or more transactions supported by the interface. 
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" Claim 7: Both the "imdesaxml" Exhibit G and the Slide 30 in Exhibit I include 
references to documents used in the particular transactions, specifying the document 
dtd's by name instead of providing a copy of them. 

" Claims 8-12 : The input and output documents in both versions are depicted as 
XML documents. Generally, XML documents compliant with the February 1998 
recommendation can be parsed or unparsed data. XML documents may encode text 
characters and the text characters may provide a natural language word. XML 
documents generally include markup data to identify sets of storage units. 

" Claim 13: The files reprinted in Exhibits D, E and H from directories 072, 075 
and ingram/01 (R 428, 476, 581) store document types that can be used in a plurality of 
transactions. Commands identified above were used to register these document types 
in a repository. Slides 25-29 (R 673-677) depict a library of document types stored in a 
repository. The dtd definitions for the documents used in the transactions are 
referenced by names. For instance, in "imdesc.xml" we see the "ack.dtd" as the output 
document for several service functions. 

" Claim 14: The collections of files from directories include "imarkprt.dtd" and 
"imarkdsc.dtd" for market participant information and market description information. 
These modules are called out in Slide 28 of Exhibit I (R 676) by slightly different and 
more easily readable names, "markpart.dtd" and "markdesc.dtd". Some of these 
document types include identifications of participant processes. 

" Claim 15: The dtd files referenced in "imdesc.xml" (R 578) and Slide 30 (R 678), 
e.g., order.dtd and ack.dtd, are recognizable as compliant with a standard Extensible 
Markup Language XML. 

" Claim 16: The file "imdesc.xml" and the code excerpt in Slide 30 are 
recognizable as compliant with a standard Extensible Markup Language XML. 

" Claim 61 : In the course of creating "imdesc.xml" and Slide 30, the authors of 
those documents went through the process of defining a machine readable interface 
definition including an input and output document. The versions of the transaction 
interface definition data structure were provided to network nodes that requested the 
definition data structures. 

" Claim 62: The data type specifications in the exemplary "order.dtd" include at 
least one logical structure. Similarly, slides 25-29 (R 673-677) depict using logical 
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structure building blocks to construct documents such as a purchase order (po.dtd). In 
general, a data type definition file (dtd) will include data type specifications for at least 
on logical data structure. 

" Claim 63: The data type specifications for the country field of the exemplary 
"order.dtd" (Exhibit E, R 476) include at least one data structure mapping predefined 
sets of storage units for a particular logical structure in the definitions to respective 
entries in a list. The country code field is supported by a list in "codes. mod" (the codes 
module), which is incorporated into addresso.mod which, in turn, is part of order.dtd. 
With a bit of tracing from imdesc.xml, one can see where the reusable lists were part of 
the system. Use of country codes in addresses is a feature of CBL that extended the 
XML recommendation -the XML recommendation uses codes for language 
identification and not for addresses. See, W3C Recommendation, Extensible Markup 
Language (XML) 1.0, § 2.12 (Feb. 10, 1998) (R 206) accessed at 
http://www.w3.Org/TR/1998/REC-xml-19980210#dt-app. Turning to the July 25, 1998 
presentation, slides 27-28 (R 675-676) similarly illustrate use of country codes in a 
purchase order, defined by the file "po.dtd". 

" Claim 64: Slide 23 (Exhibit I, R 671) depicts a service registration document in a 
registry accessible to discovery nodes on a network. Slide 31 (R 679) indicates that 
CBL was already in use for demonstration applications, Project Seitai and GSA catalog 
interoperability. We found it very useful to post our interface definitions for programmers 
to rely on during development, such as the imdesc.xml interface definition. In the 
January 1998 and earlier materials (Exhibits. D, E and H, R 428, 476, 581), we have 
printed some libraries of logical structures that we were using then. The Slides indicate 
that the libraries of logical structures were still in use six months later, when the 
conference presentation was made in July 1998. 

" Claim 65: Looking through files from the ingram/01 directory (Exhibit H, R 581) 
one finds how imdesc.xml has been defined. Beginning with imdesc.xml on page 32 of 
66 (R 613), one sees reference to "imarkdsc.dtd" in the DOCTYPE statement of line six. 
This data type definition appears on page 29 of 66 (R 635), and incorporates by 
reference the "isrvprim.mod" module that appears on page 54 of 66. The isrvprim.mod 
defines elements of imdesc.xml, indlucing service. name, service. location. pointer, and 
service/function. Thus, the sample "imdesc.xml" machine readable specification of 
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Exhibit G (R 578) complies with the imarkdsc.dtd definition of an interface document 
including logical structures for storing identifiers (e.g., service. name and/or input 
doctype) and references to definitions (dtd's) of input and output documents. Similarly, 
in Exhibit I, slide 30 (R 678), identifiers of particular transactions appear as "Submit 
Order" and "Track Order." The references to definitions of the input and output 
documents are dtd file names. The "Loose Coupling" via Shared Document Definitions 
slide 22 (R 670) makes it clear that the definition in slide 30 is a document that complies 
with a dtd, as in the ingram/01 files. 

" Claims 66-70: The input and output documents in both versions (code and 
presentation) are depicted as XML documents. Generally, XML documents compliant 
with the February 1998 recommendation can be parsed or unparsed data. XML 
documents may encode text characters and the text characters may provide a natural 
language word. XML documents generally include markup data to identify sets of 
storage units. 

" Claim 71: The dtd files referenced in "imdesc.xml" (R 578) and Slide 30 (R 678) 
are recognizable as compliant with a standard Extensible Markup Language XML. 

" Claim 72: Our development work in 1997-98 included applying parsers to input 
documents, generating one or more Java event signals in response to the logical 
structure of the input documents, and having event listener programs respond to the 
event signals." 

5. Facts Regarding Limitations in Individual Claims for Which 

McKendrick Provides No Written Description or Enabling Disclosure. 

Claim 1 : McKendrick's 53 words (R 192) do not give a written description or 
enabling disclosure of "providing a machine readable specification providing a definition 
of an interface to transaction processes stored in memory, accessible by at least one 
node in the network, including providing a definition of an input document, and a 
definition of an output document ," because the manner in which "XML will allow 
[processes involving purchase orders and invoices] ... to be implemented" is not 
described by McKendrick. 

The interface definition technology of claim 1 is exemplified by (but not limited to) 
three program code embodiments, the January 2, 1998 Exhibit G; the July 25, 1998 
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slide 30, Exhibit I (R 678), and the Application page 45 (R 120) example. (See Decls. 
§§ 14-17, R 392-394) 

Applicants' provided multiple working examples of interface definition technology. 
In contrast, McKendrick (R 192) refers to purchase orders and invoices in the future 
tense, referring to business processes that XML "will allow ... to be implemented." 

While purchase orders and invoices could be inputs and outputs to some future 
system that McKendrick expected to be developed, it is not inherent in using XML that a 
purchase order would be processed through a document-style interface, as opposed to 
an RPC interface. One using the XML-RPC recommended by Microsoft in 1998 for 
purchase orders and invoices, with the binding behaviors described in Merrick et al., US 
7,028,312, XML Remote Procedure Call (XML-RPC), cols. 22-23, (R 838-839), would 
have no need to use the claimed interface definition technology. 

Using XML documents does not inherently involve "providing a definition of an 
interface to transaction processes stored in memory, accessible by at least one node in 
the network, including providing a definition of an input document, and a definition of an 
output document." Documents written in XML could be used for transactions without the 
particular claimed definition of an interface. For instance, a buyer could send an XML 
document purchase order and a DTD file for the purchase order by e-mail to a supplier, 
without relying on the claimed interface definition technology. 

McKendrick includes an illustration of 
a web page (R 192), as set out in the 
margin, on which the Examiner has not 
relied. If this is considered a web site 
interface, as the Board has suggested 
(R 27), then one of ordinary skill in the art 
would understand that this interface does 
NOT to include " providing a definition of an 
interface to transaction processes stored in 
memory, accessible by at least one node in 
the network, including providing a definition 
of an input document, and a definition of an 
output document." The illustration appears 
{ooi43569.doc} Page 15 




tim temtmstem FfaamSis Serves. 



Application No. 09/173,858 



Atty Docket No.: OIN 1004-1 



to be a static HTML page that is accessed without an input document and that serves 
an HTML page without an output document or any interface definition. All that accessing 
a web page required in 1998 was an HTML-enabled browser - that was the beauty of 
HTML. The illustration does not provide a written description or enabling disclosure of 
whatever technology was used to create it. 

Claim 5 : The Examiner has acknowledged (R 43) that neither McKendrick nor a 
combination with the XML 1 .0 Recommendation teaches extending the machine 
readable specification to include "a document compliant with a definition of an interface 
document including logical structures for storing an identifier of a particular transaction , 
and at least one of definitions and references to definitions of input and output 
documents for the particular transaction." 

Claim 6 : Page 1 3 of the XML 1 .0 Recommendation (R 207), on which the 
Examiner relies (R 43), does not teach using "a document compliant with a definition of 
an interface document logical structures for storing an identifier of the interface, and for 
storing at least one of specifications and references to specifications of a set of one or 
more transactions supported by the interface," because page 13 does not provide an 
interface document type or a definition of an interface document. The XML 1 .0 
Recommendation does not teach the claimed interface documents type because it is a 
language definition, not an application of the language to building interfaces for 
e-commerce. 

Claim 7 : The Examiner has acknowledged (R 43-44) that neither McKendrick nor 
the XML 1 .0 Recommendation teaches an implementation of the claimed machine 
readable specification by "references", as including "a reference to a specification of a 
particular transaction, and the specification of the particular transaction includes a 
document including logical structures for storing at least one of definitions and 
references to definitions of input and output documents for the particular transaction." 

One of skill in the art, after reading this specification, would understand a 
"reference to a specification", which is used in the claims as an alternative to the 
specification itself. The Application exemplifies a "reference" as a pointer that is followed 
in order to reach the specification. (R 82, line 18) 

Claim 13 : The Examiner has acknowledged (R 47) that neither McKendrick nor a 
combination with the XML 1 .0 Recommendation teaches an implementation "including a 
{ooi43569.doc} Page 16 



Application No. 09/173,858 



Atty Docket No.: OIN 1004-1 



repository stored in memory accessible by at least one node in the network of document 
types for use in a plurality of transactions, and wherein the definition of one of the input 
and output documents includes a reference to a document type in the repository." 

What the Examiner claims to have been "well known" (R 47) is a data dictionary 
for a database or programming system. Well-known data dictionaries, circa 1998, did 
not include the claimed transaction specifications including definitions of input or output 
documents. 

Claim 14 : Page 9 of the XML 1 .0 Recommendation (R 203), on which the 
Examiner relies (R 46-47), does not teach extending a repository implementation, 
"wherein the repository of document types [further] includes a document type for 
identifying participant processes in the network," because page 9 does not provide a 
participant identifier document type or a definition of a participant identifier document. 
The XML 1 .0 Recommendation it is a language definition, not an application of the 
language. 

Claim 16 : Page 9 of the XML 1 .0 Recommendation (R 203), on which the 
Examiner relies (R 51 ), does not teach requiring the machine readable specification to 
be "a document organized according to a document type definition compliant with a 
standard Extensible Markup Language XML," because page 9 does not teach using 
XML for an interface specification document that, in turn, refers to definitions of XML 
documents to be used as input and output documents. The XML 1 .0 Recommendation 
does not include these multiple levels of interface definition structure because it is just a 
language definition. 

Claim 61 : This claim is for a method for programming a commercial transaction 
in a network that applies the interface definition technology of claim 1 . Reading the 
claim, one sees that the input and output documents are defined and provided to a node 
being programmed, which includes resources to execute a process in the transaction. In 
dependent claim 72, the programming method further includes providing a parser 
responsive to the input document definition and providing event listeners responsive to 
the event signals generated by the parser. 

None of the Examiner's analysis of claim 61 (R 48-50), takes into account that 
claim 61 is a method for programming a commercial transaction. 
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The Examiner has acknowledged (R 48-49) that McKendrick does not explicitly 
disclose any of the claimed limitations. That is, McKendrick does not explicitly disclose a 
method for programming a commercial transaction in a network, comprising: " defining a 
machine readable definition of an input document for a node in the network including 
resources to execute a process in the transaction, and a machine readable definition of 
an output document for the node, the definitions of the input and output documents 
comprising respective descriptions of sets of storage units and logical structures for the 
sets of storage units; and providing interpretation information for the logical structures to 
the node ." 

The Examiner cited no evidence to support the Examiner's inherency contention 
(R 49) that, "Since the purchase orders as well as the invoices [in McKendrick], which 
are [considered by the Examiner to be] the input and output documents, are in XML 
format, they definitely include information to provide the definition for said documents 
according to the XML structures." This inherency contention is contradicted by the 
mechanism provided in the XML 1 .0 Recommendation, § 2.8 (R 202-204), for defining 
constraints on the logical structure of an XML document and to support the use of 
predefined storage units is an XML document type declaration . An XML document type 
definition contains or points to markup declarations for a class of documents and 
appears in the code near the beginning of the XML document itself. The example given 
in the Recommendation illustrates (R 204) an embedded DOCTYPE "greeting" 
(between [ ]) that defines the ELEMENT of the greeting, without any external interface 
or document definition: 

<?xml version="1.0" encoding="UTF-8" ?> 

<! DOCTYPE greeting [ 

<!ELEMENT greeting (#PCDATA)> 

]> 

<greeting>Hello, world !</greeting> 
Therefore, use of XML for purchase orders and invoices does not inherently include the 
claimed interface definition technology. 

The Examiner cited no evidence to support the Examiner's contention (R 50) 
that, "McKendrick discloses the transaction documents such as the purchase orders 
and the invoices in XML format for a business transaction over the Internet where a 
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user can search and buy an item on-line." There is no evidence of record that 
Microsoft's browser was XML-enabled in September 1998. It was not until November 4, 
1998, that Microsoft announced the availability of a beta version of Microsoft Internet 
Explorer 5 for technical evaluation. See http://xml.coverpages.org/xmlMicrosoft.html (not 
of record). 

Using a browser on-line to search for and buy goods as the Examiner describes 
(R 50), has nothing to do with claim 61 , because on-line browsing does not describe a 
method of programming a commercial transaction in a network. 

Claims 62-71 : No separate facts are provided for these claims, as they modify 
claim 61 in terms similar to claims 2-6, 8-12 and 15, which depend from claim 1. 
Moreover, the Examiner made a "same rationale" rejection of these claims. (R 50) 

Claim 72 : The Examiner has acknowledged (R 50) that neither McKendrick nor a 
combination with the XML 1 .0 Recommendation teaches extending a method for 
programming by " providing a parser to generate event signals in response to logical 
structures in the definition of the input document : and providing event listener programs 
which respond to the event signals to execute the process." 

One useful application of the claimed method for programming is implementation 
of a "marshaling program" to convert an input document into an internal representation 
that the transaction processing program uses. (Application, R 164) The Examiner's 
analysis is unresponsive to using the claimed method for programming. (R 50-51) 

The Examiner cited no evidence to support the Examiner's modification of the 
cited references (R 51): "It would have been obvious to one of ordinary skill in the art at 
the time of the invention was made to have modified McKindrick [sic] to include 
'providing a parser to generate event signals in response to logical structures.. .' and 
'providing event listener program which respond to the event signals to execute the 
process' for the following reason." Neither a reference nor official notice is cited as a 
source of the elements that the Examiner acknowledges are missing. 

Claims 73-74 : These claims differ from claims 1-2 in that the claimed interface is 
"to an operation", instead of "to transaction processes". 

The Application teaches an interface to operations in many places, including 
pages 17, 25-27, 30, 66, 70-79, and 88. (R 92, 100-102, 105, 141, 145-154, 163) In 
Figure 2 (R 61), reference 210 is referred to as an operation performed by a service. 
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(See, Applic, at 17, R 92) The sample code in the application typically uses the 

nomenclature, "Service Operations". (R 100-102, 105, 141, 145-154, 163) 

Separate facts for claims 73-74 are not needed, because of how closely claims 

73-74 resemble claims 1-2. 

B. The Examiner Erred in Rejecting Each of the Pending Claims 1-16 and 61- 
74 Under 35 U.S.C. § 103(a) Because the Undisputed Evidence Establishes 
Actual Reduction to Practice of the Claimed Technology Before the 
September, 1998 Publication of McKendrick's Brief Article. 

Rejection of the claims is improper because it depends on McKendrick, which 
has been effectively removed as a reference. On its face, the inventors' and non- 
inventor's testimony swears behind the McKendrick reference, as the inventors actually 
reduced the claimed technology to practice and tested it sufficiently to understand that it 
would work for its intended purpose before McKendrick's brief article published in 
September, 1998. 

1. The Examiner Erred in Rejecting Claims 1-16 and 61-74 Because the 
Undisputed Evidence of Record Proves Actual Reduction to Practice 
Before January 21, 1998, in Preparation for a Scheduled 
Demonstration to a Prospective Customer. 

The Examiner erred in the Office Action of October 9, 2008, by failing to give any 
evidentiary weight to sections 13-16 and 19 (R 390-400) of the declarations and the 
supporting exhibits (R 402-685), which provide well-corroborated testimony of an actual 
reduction to practice before January 21, 1998. 

Failure to give any consideration to sworn testimony is reversible error. Ex parte 
Ovshinsky, 10 U.S.P.Q.2d (BNA) 1075 (Bd. Pat. App. & Inter. 1989). In that case, the 
Board held, "This failure to give probative weight to the Rule 131 declarations 
constitutes reversible error. ... [I]t is entirely appropriate for appellant to rely on a 
showing of facts set forth in the Rule 131 declarations themselves to establish 
conception of the invention prior to the effective date of the reference. This appellants 
have done." The Ex parte Ovshinsky decision cites Ex parte Swaney and Banes, 89 
U.S.P.Q. (BNA) 618 (Bd. Pat. App. & Inter. 1950), another case in which the Board 
reversed the examiner and held that the declarations offered were sufficient, even 
without written corroboration of all the elements of the claims. 

This Examiner failed to give any weight to sections 1 3-1 6 and 1 9 of the 
declarations or to the supporting exhibits - she ignored the evidence. (R 54-57) The 
{ooi43569.doc } Page 20 



Application No. 09/173,858 



Atty Docket No.: OIN 1004-1 



declarations are detailed, highly credible, and thoroughly corroborated by specific 
reference to many documents as set forth in the Statement of Facts. It is reversible error 
to ignore facts set forth in the Rule 131 declarations. 

In the first appeal, the Board instructed that it is Applicants' burden, regardless of 
the Examiner's analysis, to clearly explain how the proffered evidence shows 
completion of the invention. (R 8) To shoulder this burden, Applicants presented facts in 
detailed declarations (Decls. §§ 6-20, R 388-400), corroborated by many exhibits and 
explained by extensive briefings. (R 293-322) On appeal, our Statement of Facts is 
presented on a claim-by-claim basis. 

Earlier in the case, the Board recited the following standard forjudging Rule 131 
declarations: Applicants must "show prior 'possession of either the whole invention 
claimed or something falling within the claim, in the sense that the claim as a whole 
reads on it.' See In re Tanczyn, 347 F.2d 830, 833, 146 USPQ 298, 301 (CCPA 1965). 
Applicants can show 'priority with respect to so much of the claimed invention as the 
reference happens to show.' See In re Stempel, 241 F.2d 755, 759-60, 113 USPQ 77, 
81 (CCPA 1957)." (R 24) 

The reference that sets the standard for "showing so much as the references 
happens to show" is McKendrick's brief article. McKendrick sets a low hurdle because 
what it says in the 53 words (R 192) on which the Examiner relies, is essentially that 
XML provides an opportunity for developing applications in the future that could handle 
purchase orders and invoices. 

Applicants have carried their burden, regardless of whether the detailed 
declarations and corroborating exhibits are judged against McKendrick or against the 
claims. Our showing is overwhelming, when compared to McKendrick. Moreover, the 
declarations and exhibits have been carefully mapped to the claims. The evidence is 
detailed, persuasive and not criticized in the record. Against any standard, Applicants 
have carried their burden. 

The facts in Ex parte Ovshinsky are on all fours with this case, because that 
examiner made the same mistake as this one: Both refused to give any evidentiary 
weight to declaration testimony or to the exhibits. The Board reversed that Examiner 
and should reverse this one as well. 
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2. The Examiner Erred in Rejecting Claims 1-16 and 61-74 Because the 
Undisputed Evidence of Record Proves Actual Reduction to Practice 
on or before July 25, 1998, When Dr. Glushko Described Actual Use 
of the Claimed Technology at the International Workshop on 
Component-Based Electronic Commerce, Haas School of Business, 
University of California, Berkeley 

The Examiner erred in the Office Action of October 9, 2008, because she ignored 
sections 1 4-1 7 of the declarations (R 392-394) and gave no weight to Exhibit I, slide 30 
(R 678), which provide well-corroborated testimony of an actual reduction to practice on 
or before July 25, 1998. 

Again, failure to give any consideration to inventors' sworn testimony is reversible 
error. Ex parte Ovshinsky, supra. Inventors' declarations under Rule 131 are not the 
only kind of evidence that the Examiner is required to consider. The Rules (e.g., current 
Rule 131 and predecessor Rule 75) describe a safe harbor for showing actual reduction 
to practice prior to the date of a reference, but the rules do not and cannot limit the 
statute (§ 102) or limit the alternative ways of proving actual reduction to practice. Ex 
Parte Foster, 105 O.G. 261 (Comm'r Pat. 1903) (accepting non-inventor declaration); 
MPEP § 715.04 (citing Ex Parte Foster as good authority, 105 years later). 

We presented proof of reduction to practice on or before July 25, 1998 in two 
rounds of briefing. (R 315-317, 240-250) The Examiner erred in giving no probative 
weight to Exhibit I, slide 30, because she only criticized slide 30 in isolation. (R 53) The 
Examiner erred by ignoring the context set in the inventors' testimony (Decls. §§ 14-17) 
and ignoring other slides in the same presentation that show, inter alia, that Dr. Glushko 
was demonstrating technology already used successfully in two trials: Project Seitai and 
GSA catalog interoperability. (Exhibit I, slide 31, R 679; Decls. § 19, Claim 4, R 396) 
The Examiner further erred in failing to consider the similarities among the imdesc.xml 
data structure, dated January 2, 1998 (Exhibit G, R 578), the slide 30 data structure, 
disclosed July 25, 1998 (Exhibit I, R 678), and the data structure disclosed on page 45 
of this Application. (Application, R 120; Briefing, R 310) These similarities demonstrate 
that the January 2, 1998 embodiment was ready to work for its intended purpose. 

Applying the In re Stempel rule set forth above, our position is that slide 30, in the 
context of the July 25, 1998 presentation and as explained in the declarations, proves 
much more than McKendrick. Accordingly, Applicants have met the general burden to 
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remove McKend rick's brief article as a reference. In re Stempel, supra, 241 F.2d at 759- 
60. 

3. The Examiner Erred in Rejecting the Claims Based on McKendrick's 
Brief Article Because the Undisputed Evidence Regarding Each of the 
Claims 1-16 and 61-74 Removes McKendrick as a Reference. 

The Statement of Facts addresses reduction to practice on a claim-by-claim 
basis that is not repeated here. For each claim, the Statement recites undisputed, well- 
corroborated testimony that shows actual reduction to practice before September 1998. 

The Examiner erred in applying the wrong standard to judging how much 
evidence Applicants need to provide. (R 287 at bottom, 54, 56-57) The Examiner's 
requirement that Applicants need "evidence of a complete product that is guaranteed 
that it worked with testing" (R 287), misstates the applicable rule of law. Applicants need 
not have completed a commercial product and need not have guaranteed that it worked 
based on extensive testing. "[I]n order for there to be a reduction to practice, there is no 
requirement that the invention when tested be in a commercially satisfactory stage of 
development." King Instrument v. Otari Corp., 767 F.2d 853, 861, 226 U.S.P.Q. 402 
(Fed. Cir. 1985) cert, denied 475 U.S. 1016 (1986). "Some devices are so simple and 
their purpose and efficacy so obvious that their complete construction is sufficient to 
demonstrate their workability." Mahukarv. C.R. Bard, Inc., 79 F.3d 1572, 1578, 38 
U.S.P.Q.2D 1288 (Fed. Cir. 1996) (citing King Instrument). 

A demonstration prototype is enough to prove that this invention would work for 
its intended purpose. See King Instrument, supra. The prototype prepared for 
demonstration to Ingram Micro is enough. The witnesses have testified that they tested 
the prototype sufficiently to appreciate that it was workable; while preparation for the 
important demonstration to Ingram Micro involved substantial effort and testing. 
Alternatively, there is no evidence of or argument that the elegant imdesc.xml data 
structure would have required any testing to show that it would work for its intended 
purpose. See Mahukar, supra. While we have not attempted to prove that VEO had a 
completed product in January 1998, we have proven that these inventors 1997 concept 
was tested before McKendrick was published and that the inventors correctly 
appreciated that the inventive data structure would work, which is enough to remove 
McKendrick as a reference when the correct legal standard is applied. 
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C. The Examiner Erred in Rejecting Each of the Pending Claims 1-16 and 61- 
74 under 35 U.S.C. § 103(a) Because the Undisputed Evidence Establishes 
That One of Ordinary Skill in the Art Would Not Find McKendrick's Brief 
Article in Combination With the XML v1.0 Recommendation to Provide a 
Written Description or Enabling Disclosure of the Claimed Interface 
Definition and Programming Technologies. 

Even if McKendrick is not removed as a reference, the brief article in combination 

with the XML 1 .0 Recommendation fails to provide a written description or enabling 

disclosure of what we claim, when the Board applies the same standard to McKendrick 

as to the Rule 131 declarations. C.f., In re Stempel. 

1. The Examiner Erred in Failing to Evaluate the Level of Ordinary Skill 
in the Art, circa 1998, Based on the Evidence of Record. 

It is fundamental that application of the Section 103 obviousness test includes 
considering the level of ordinary skill in the art. KSR International Co. v. Teleflex, Inc., 
550 U.S., 127 S. Ct. 1727; 167 L. Ed. 2d 705; 82 U.S.P.Q.2D (Apr. 30, 2007) and Ex 
parte Jud, Appeal No. 2006-1061, 2007 Pat. App. LEXIS 9, (BPAI Jan. 30, 2007) 
(expanded panel, informational opinion). This has been the case since Graham v. John 
Deere, 383 U.S. 1,17-18 (1966), as we repeatedly have argued. (R 305, 258-260) 

The Examiner erred when she refused to consider the substantial evidence that 
we submitted regarding the level of skill in the art, circa 1998, on the basis of res 
judicata. (R 54-55). It is black letter law that an examiner must not apply res judicata 
when new evidence is submitted after appeal. In re Donohue, 766 F.2d 531 , 533, 226 
U.S.P.Q. 619 (Fed. Cir. 1985); In re Herr, 377 F.2d 610, 153 USPQ 548 (CCPA 1967); 
In re Russell, 439 F.2d 1228, 169 USPQ 426 (CCPA 1971); and In reAckermann, 444 
F.2d 1172, 170 USPQ 340 (CCPA 1971). The Office's instructions to examiners are 
consistent with the case law, as MPEP § 706.03(w) reports that new evidence was not 
subject to res judicata and that rejections on that basis were reversed in the cases In re 
Donohue, In re Herr, In re Russell and In re Ackerman . We cited this authority and 
reminded the Examiner that the Board expressly invited us to submit our new evidence 
to the Examiner. (R 314-315) The Examiner's response (R 18-21) ignored the cases 
and Board's invitation. Refusal to follow the law is reversible error. 
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2. The Examiner Erred Failing to Reevaluate McKendrick's Brief Article 
in View of the Level of Ordinary Skill in the Art, circa 1998, and in 
View of Evidence Regarding the Microsoft Initiatives That 
McKendrick Was Reporting. 

The level of skill in the art reflected in Exhibits A, B, K, and M-U belies the 
Examiner's interpretation of McKendrick. The combined effect of this evidence is to 
demonstrate that the level of ordinary skill in the art was very low in 1998, in the months 
immediately following W3C's publication of the XML 1 .0 Recommendation, and that 
Microsoft was advocating development of XML-RPC technology for application of XML 
to commercial transactions. Microsoft's XML-RPC technology could readily be practiced 
without using VEO's claimed technology. 

It is black letter law that references relied upon for a section 103 rejection must 
provide an enabling disclosure, i.e., they must place the claimed invention in the 
possession of the public. 1 Chisum on Patents § 3.04 [1][b][v] to [1][c]. Printed 
publications cited as prior art must be enabling. In re Epstein, 32 F.3d 1559, 1568, 31 
U.S.P.Q.2d (BNA) 1817 (Fed. Cir. 1994); Chisum, supra, citing, In re Brown, 329 F.2d 
1006, 141 USPQ 245 (CCPA 1964); In re Payne, 606 F.2d 303, 314-15, 203 USPQ 245 
(CCPA1979). 

The Statement of Facts recites the low level of skill in the art in September 1998, 
when these inventors were keynoting major conferences and responding to questions 
from attendees of ordinary skill in the art. Recall that on September 1, 1988, the 
audience asked Dr. Glushko whether XML was "stable, politically and otherwise", to 
which the inventor responded somewhat equivocally. In 1998, the level of ordinary skill 
was represented by the skeptical audience , not by the keynote speaker who was 
unveiling new technology. 

The Statement of Facts shows that one of ordinary skill in the art would have 
found Microsoft advocating development and future use of XML-RPC, upon following up 
on McKendrick's brief article. The evidence of record ties Microsoft to XML-RPC. There 
is no evidence of record that Microsoft was using or advocating the claimed interface 
definition and programming technology. 

Therefore, no one of ordinary skill in the art, reading McKendrick's brief article in 
1998, would have considered the article to be an enabling disclosure or proof that the 
reporter was in possession of the claimed technology. Those of ordinary skill in the art, 
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comparing our application on October 16, 1998 to McKendrick's brief article a few 
weeks earlier, could not have considered McKendrick to have been in possession of 
what these inventors disclosed and claimed. 

When McKendrick's brief article is considered in light of evidence regarding the 
level of ordinary skill in 1998 , we see why McKendrick was writing about what would 
happen in the future , how "XML will allow companies to cooperate on product design 
and development", how "XML will allow a rich array of business applications to be 
implemented", instead giving a written description of something that already existed. In 
1998, McKendrick says at pages 1-2, that use of XML was primarily buzz and potential, 
not working products. 

In view of the new evidence regarding the level of skill in the art that the 

Examiner did not consider, we ask that the Board reverse the Examiner's expansive 

reading of McKendrick and the rejections based on that brief article. 

3. The Examiner Erred in Rejecting the Claims (Grouped as 1, 2, 4, 8-12, 15, 
73 & 74; 5-6 & 65; 7; 13; 14; 16; 61; 6, 66-71; and 72) Under Section 
103(a) Because the References Cited Fail to Provide a Written 
Description or Enabling Disclosure of the Claimed Technology. 

Applicants argued before and after appeal that McKendrick's brief article does 
not provide a written description or enabling disclosure of any of the technology found in 
the specification, drawings and claims. Our focus in the past has been on limitations 
found in the independent claims, limitations related to XML as an implementation of the 
claimed interface definition technology, and the role of repositories in making available 
the claimed interface definitions. The limitations previously discussed in detail can be 
found in claims 1, 2, 4, 13, 14, 15, 16, 61, 62, 64, 71, 73 and 74. 

This paper presents a more detailed analysis of how the limitations in individual 
claims are missing from McKendrick and from the combinations on which the Section 
103 rejections based. It would have been futile to present this detailed analysis to the 
Examiner, as the Examiner took the mistaken position that res judicata prevented her 
from considering any arguments regarding the claims, unless the claims were amended. 
(R 54-55) 
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a. The Examiner Erred in Rejecting the Claims 1, 2, 4, 8-12, 15, 64, 
73 & 74 Under Section 103(a) Because the References Cited 
Fail to Provide a Written Description or Enabling Disclosure of 
the Claimed Technology. 

We suggest that the Board consider claim 15 to be representative of this group of 
claims, as the Application (R 80, line 1) and our previous papers use XML as one 
example of a document encoding for input and output documents may embody in the 
claimed interface definition technology. Claim 15 adds to claim 1 the use of XML 
document type definitions (DTD). 

The Examiner rejects claim 1 on the basis of McKendrick in view of the XML 1 .0 
Recommendation. (R 40-42) Following the first appeal, the Examiner refused to 
consider any argument regarding application of McKendrick to unamended claims, on 
the basis of res judicata. (R 53-55). Applying res judicata was error, as explained above, 
because res judicata does not apply when new evidence is submitted. 

The Examiner erred in failing to evaluate the level of ordinary skill in the art, 
based on post-appeal evidence. This impacted the Examiner's interpretation of 
McKendrick for the reasons given above. 

The Examiner erred when she interpreted claim 1 in a manner that does not 
particularly read on the exemplary embodiment provided on page 45 of the Application 
(R 120) and the additional examples in newly-submitted Exhibits G and I. Patent claims 
should be interpreted, if practical, in a manner that reads on at least one of the 
embodiments disclosed. Interpretation of the claims must be consistent with the 
interpretation that those skilled in the art would reach in light of the specification. MPEP 
§§ 201 1 -201 1 .01 . The court must always read the claims in view of the full specification. 
Vitronics Corp. v. Conceptronic, Inc., 90 F.3d 1576, 1583 (Fed. Cir. 1996). A claim 
construction that excludes a preferred embodiment, moreover, "is rarely, if ever, 
correct." Helmsderfer v. Bobrick Washroom Equip., 527 F.3d 1379, 1383, 87 U.S.P.Q. 
2d (BNA) 1216 (Fed. Cir. 2008); Vitronics, 90 F.3d at 1583; see also C.R. Bard, Inc. v. 
U.S. Surgical Corp., 388 F.3d 858, 865 (Fed. Cir. 2004). 

Instead of reading this claim on an interface definition technology, the Examiner 
effectively interpreted the claim to apply to any process related to an XML purchase 
order and an XML invoice. (R 40-42) This is the consequence of the Examiner's 
analysis, intended or not, because her application of McKendrick to the claim gives no 
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weight to the requirement for a machine readable specification of an interface, as 
claimed and exemplified in the Application. (R 120) McKendrick says nothing about any 
interface definition. The Examiner's interpretation is erroneous because it is contrary to 
the words the of the claim and is inconsistent with the technology disclosed in the 
exemplary embodiments. 

The Examiner erred in arguing that McKendrick, by itself, discloses a machine- 
readable specification of an interface to transaction processes, including interpretation 
information providing a definition of an input document and a definition of an output 
document. (R 40). The level of skill in the art needs to be taken in account when 
McKendrick's brief article is interpreted. Ex parte Jud, Appeal No. 2006-1061 (Jan. 30, 
2007) (expanded panel, informational opinion); (R 258-259). Two factors that Ex parte 
Jud identified as useful in evaluating the level of skill in the art were the level of detail in 
the applicants' disclosure and documentary evidence or references that were prepared 
for reasons other than use as evidence in patent prosecution. Id. at 4-5. In this case, the 
1998 application was over 100 pages long, because the technology was new. It 
included extensive samples of code to enable practice of the invention. The Statement 
of Facts describes 1998 as the earliest early stage of applying XML to e-commerce. The 
Examiner mistakenly applied res judicata and, on that basis, declined to view 
McKendrick in light of the level of ordinary skill in the art, circa 1 998. If the Examiner 
had applied the perspective of one of ordinary skill in the art, McKendrick clearly would 
not be considered enabling. 

McKendrick does not provide a written description or enabling disclosure of any 
interface definition technology. Given the level of skill in the art, the Examiner erred in 
combining the identification of Innovision's OFX product (McKendrick, at 1, R 191) with 
remarks attributed to Microsoft (R 192) as a basis for "applying XML in financial area 
[sic] to provide better bank services and utilizing XML for on-line business transactions." 
(R 40) The mention of Innovision's OFX product 1 is not enough to qualify as a written 



1 A trial judge might well exclude McKendrick from consideration by applying the Best 
Evidence Rule (Fed. R. Evid. 1002), to the extent that the brief article repeats hearsay 
statements Innovision's product and Microsoft's reports. No expert witness would dare 
stake their credibility on McKendrick, without of tracking down the Innovision product 
and the original Microsoft report. 
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description or enabling disclosure of any interface definition technology -- it does not 
mention an interface definition or make any effort to teach how to build one. The brief 
article that only mentions Innovision's new product cannot be treated as providing a 
written description or enabling disclosure of the product. In re Epstein, supra. The 
attribution of certain remarks to Microsoft (R 192) includes only statements about how 
XML would, in the future , allow development of a rich array of business applications not 
yet implemented. The combination of these two passages provides names of two 
companies that might be contacted, but does not provide a patent law "written 
description" or "enabling disclosure" sufficient to teach one of ordinary skill in the art, 
circa 1998, how use the new XML programming language to develop the claimed 
interface definition technology. 

The Examiner erred in reasoning that the quote from Microsoft, which mentions 
purchase orders and invoices in the context of potential future development, disclosed 
XML documents that "definitely include information providing the definition for such a 
document according to XML structures." (R 41) First, this reasoning does not read on 
the claimed interface definition technology. The reasoning ignores structure described 
as the machine readable interface specification limitations. Second, as set forth in a 
Statement of Facts, the XML programming language allows options for providing data 
type definitions. The XML language permits the documents referred to in McKendrick to 
be used without any machine-readable specification of an interface. The XML language 
allows documents to be self-describing, that is to carry their own datatype definition in 
the first few lines the XML document. Therefore, the reasoning about what might be 
inferred from the Microsoft quote in McKendrick does not qualify as prior art and does 
not support a rejection under Section 103. 

The Examiner further erred in characterizing McKendrick as disclosing that "the 
transaction documents such as purchase orders and invoices in XML format for a 
business transaction over the Internet or user can search and buy an item online." 
(R 41, Examiner's underlining). McKendrick discloses the possibility of future 
development that would use XML with purchase orders and invoices. McKendrick does 
not disclose using XML over the Internet for a consumer to search and buy an item 
online. As indicated in a Statement of Facts, those of ordinary skill in the art in 1998 
would not expect browsers to use XML. It is difficult to imagine how use of XML in 
{ooi43569.doc } Page 29 



Application No. 09/173,858 



Atty Docket No.: OIN 1004-1 



browsers for consumer online shopping would have anything to do with the claimed 
interface definition technology. The Examiner's proposed combination of McKendrick 
and the XML recommendation to produce a consumer Internet browser application used 
to "search and buy an item online" leads away from the claimed invention, rather than 
reading on it . 

The Examiner erred in combining the XML language support for datatype 
definition (DTD) requirement with McKendrick to meet the limitations of claim 1 5. (R 48) 
Claim 15 describes one embodiment of a machine readable specification for an 
interface definition that uses DTD definitions compliant with XML to define input and 
output documents. This use of DTD definitions is illustrated in Exhibit G (imdesc.xml), 
Exhibit I (slide 30) and on page 45 of the Application. (R 578, 678, 120) Comparing 
page 9 of the XML 1 .0 Recommendation (R 203), one sees that the XML language 
definition does not illustrate or suggest using DTD definitions in the manner depicted by 
the exhibits and the Application or as claimed. 

Each of the errors committed by the Examiner during examination of claim 1 are 

considered by Applicants to be sufficient to justify reversal of the rejection under Section 

1 03 of this group of claims. 

b. The Examiner Erred in Rejecting the Claims 5-6 & 65 Under 
Section 103(a) Because the References Cited Fail to Provide a 
Written Description or Enabling Disclosure of the Claimed 
Technology. 

As the Board considers these and the other dependent claims, we hope that will 
better appreciate the meaning of limitations in the independent claim and avoid any so- 
called "broadest reasonable interpretation" that would be inconsistent with the 
dependent claims. 

The Examiner erred in combining a data dictionary (R 43), which is well known, 
with McKendrick and the XML 1 .0 Recommendation to read on claims 5 and 65. These 
claims include limitations that require definition of an interface document type and use 
of a " document " of the defined interface document type to store an identifier of a 
particular transaction and define the interface specification. In an XML embodiment, that 
means using a document defined in XML as interface type document to hold the 
transaction identifier and definitions of other XML documents used for input and output. 
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When this claim is properly interpreted, adding a data dictionary to the other references 
is irrelevant to the claim. 

We group claims 5 and 6 together because one calls for the interface document 
type to store an identifier of a particular transaction and the other calls for storing an 
identifier of the interface . The data dictionary described by the Examiner is not an 
interface document type (such as an XML compliant user-defined interface type 
document) and the data dictionary does not store the claimed combination of a 
transaction or interface identifier, plus definitions of other documents used for input and 
output. 

Therefore, use of the well-known data dictionary technology does not result in a 
combination that reads on claims 5-6 and 65. The rejection of these claims should be 
reversed. 

c. The Examiner Erred in Rejecting the claim 7 Under Section 103(a). 

The Examiner erred in relying on the XML 1 .0 Recommendation to supply the 

particular referencing structures of claim 7 that McKendrick lacks. The Examiner 

acknowledged that McKendrick does not include a reference to a specification of a 

particular transaction or further define the structure of the referenced specification. 

(R 43-44) The passage from page 3 of the XML 1 .0 Recommendation (R 197) which the 

Examiner quotes, relates to the last element of claim 1 , not the claimed referencing 

structure. Page 3 describes how definitions of XML documents comprise descriptions of 

sets of storage units and logical structures the sets of storage units. The passage 

quoted does not address the detailed structure of claim 7. It does not refer to a 

machine-readable specification that includes a reference (e.g., a pointer) to another 

specification, with the other specification including either definitions or references to 

definitions of input and output documents. Since the elements acknowledged to be 

missing from McKendrick and are not supplied by the XML 1 .0 Recommendation they 

cannot be in the combination. Therefore, the rejection should be reversed. 

d. The Examiner Erred in Rejecting the Claim 13 Under Section 
103(a). 

One example of the technology in claim 13 is a repository of datatype definitions 
(XML DTDs) used to define either the input or output document by reference. In other 
words, the node making use of the machine-readable specification would also need to 
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access to the repository to makes sense of the interface specification. The Examiner 
erred by misunderstanding claim 13 and characterizing it as "storing all data related to 
purchase transactions" in a repository memory. (R 47, middle) Storing "any defined data 
for a program in a network" (id.) says nothing about functionality, structure, or 
interrelationship parts of the data. The Examiner erred by making general statements in 
response to this claim without properly interpreting the claim or reading the cited art on 
the claim. 

e. The Examiner Erred in Rejecting the Claim 14 Under Section 
103(a). 

Claim 14 further refines the repository of claim 13. The repository that contains 
document types (e.g., XML DTDs), further includes a document type for identifying 
participant processes in the network. The Examiner erred by referring to the existence 
of document type definitions, which are described in page 9 of the XML 1 .0 
Recommendation (R 203), without trying to find any example that applied data type 
definitions to identification of participant processes in a network. The Examiner erred by 
focusing on a feature that the XML programming language supports, rather than the 
claimed structure can be built using the XML programming language. No one of skilled 
in the art would understand the XML language support for document type declarations 
to read on our claimed implementation a repository of document types that includes a 
specific document type for identifying participant processes in the network. 

f. The Examiner Erred in Rejecting the Claim 16 Under Section 
103(a). 

Claim 16 adds to claim 1 the use of a document organized according to an XML 
document type definition to contain the claimed machine readable data specification. 
Use of an XML DTD is expressly claimed here. 

The Examiner again erred by referring to the existence of document type 
definitions, described on page 9 of the XML 1.0 Recommendation (R 202), without 
trying to find any examples of an XML document that in turn includes specifications or 
references the specifications of input and output documents, which define an interface 
definition. Support for a language feature should not be confused with sophisticated 
application of the programming language to support e-commerce. 
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g. The Examiner Erred in Rejecting the Claims 61 & 66-71 Under 
Section 103(a). 

Claim 61 is a method for programming a commercial transaction. It includes 
defining a machine readable definition of an input document and an output document for 
a node that includes resources to execute process in a transaction. It further providing 
interpretation information for the logical structures of the input and output document to 
the node . The specification explains that the node can then be programmed using the 
definitions to generate datatype definitions, marshaling routines that convert input XML 
documents into Java objects, and unmarshaling routines that convert Java objects into 
an output XML document. (R 164) 

The Examiner acknowledges the McKendrick does not explicitly disclose defining 
a machine readable definition of an input document or an output document, or providing 
interpretation information to the node that has the resources to execute the process in 
the transaction. (R 48-49) 

The Examiner's rejection (R 49-50) has nothing to do with a method for 
programming transactions. The Examiner erred by failing to interpret the claim before 
writing the rejection. Neither McKendrick nor the XML 1 .0 Recommendation describes 
how to go about programming a transaction on a node in the network. 

h. The Examiner Erred in Rejecting Claim 72 Under Section 
103(a). 

Claim 72 adds to claim 61 providing a parser for the node responsive to logical 
structures in the definition of the input document and providing an event listener 
program responsive to event signals generated by the parser. These are specific 
implementation details for programming the node that includes resources to carry out a 
transaction process. The specific implementation details underscore the significance of 
addresses these claims as a method for programming . 

The examiner erred by failing to provide a reference that includes a parser or a 
listener program. (R 50) There is no reference cited for any the elements in claim 72, 
which is reversible error. 

In conclusion, we have traversed the Section 103(a) rejections with evidence that 

removes McKendrick as a reference and evidence regarding the level of skill in the art 
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in 1998, shortly after W3C published the XML 1 .0 Recommnedation. Whether 
McKendrick's brief article is removed as a reference or properly read in light of the 
evidence of the level of ordinary skill in the art, the present claims should be allowed 
over McKendrick. We respectfully request that all of the Section 103(a) rejections be 
reversed. 

D. The Examiner Erred in Rejecting Claims 73-74 Under 35 U.S.C. § 112 
Because the Word "Operations" in Claim 73 is Readily Understood by 
Reference to the Specification and the Extensive Code Samples of "Service 
Operations." 

1. Section 112, First Paragraph. 

Rejections under Section 112, first paragraph and Section 112 second paragraph 
of claims to 73-74 are new in the latest office action. Therefore, our response in this 
paper will be new to the Examiner. We invite the Examiner to withdraw the section 112 
rejections. 

The Examiner rejects the claims under Section 112, first paragraph as failing to 
comply with the enablement requirement. However, the rationale has nothing to do with 
enablement. (R 38-39). 

The Examiner argues that an "operation", as that term is used in the 
specification, can only refer to an input document OR an output document. That is, only 
a one-way message, not a two-way exchange. This argument seems to be based on 
part of a code sample in the Application (R 1 00, line 26) that includes the quoted phrase 
"by way of input and output documents." The Examiner has erred in reading our 
specification. For instance, if the Examiner had read a few lines further on the same 
page of the application (R 101), the following description appears: 

<H3>Service Operations</H3> 

<INTRO><P>A service operation consists of a name, location and its 
interface, as identified by the type of input document that the service 
operation accepts and by the type of document that it will return as a 
result.</P></INTRO> 

<ELEMENTTYPE NAME="service.operation"> 

<EXPLAIN><TITLE>Service Operations</TITLE> 

<P>A service operation must have a name, a location, and at least one 
document type as an input, with one or more possible document types 
returned as a result of the operation. </P> 

</EXPLAIN> 
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<MODEL><SEQUENCE> 

<ELEMENT NAME="service.operation.name"></ELEMENT> 
<ELEMENT NAME="service.operation.location"></ELEMENT> 
<ELEMENT NAME="service.operation.input"></ELEMENT> 
<ELEMENT NAME="service.operation.output"></ELEMENT> 
</SEQUENCE></MODEL> 
</ELEMENTTYPE> 

This is one of several examples of an operation that involves two-way communication 
using input and output documents. 

Therefore, claim 73 is supported and enabled by the specification and the 
rejection of claims 73-74 under Section 112, first paragraph, should be reversed. 

2. Section 112, Second Paragraph. 

The Examiner further rejects claims under Section 112, second paragraph, is 
being indefinite for failing to particular point out distinctly claim the subject matter which 
the applicant regards as the invention. The Examiner questions, "how an operation is 
performed for two processes for input document and an output document." (R 39) The 
Examiner's question has no basis in the wording of the claim. Claim 73 calls for "a 
machine-readable specification an interface to an operation [singular]... including 
interpretation information providing a definition of an input document, and the definition 
of an output document..." 

As the claim wording uses a singular operation and the specification allows for 
one or more input and output documents, this rejection under Section 112, second 
paragraph should be reversed. 

Reversal of both grounds for rejection under Section 112, first and second 
paragraphs, should clear the way for allowance of these claims. 
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IX. CONCLUSION 

In view of the foregoing, Applicants ask that this honorable Board reverse the 
Examiner's rejections of the claims. In addition, it is submitted that all claims that are the 
subject of this examination are now allowable, and a notice of intent to issue a patent is 
respectfully requested. 

The Commissioner is hereby authorized to charge any fee determined to be due 
in connection with this communication, or credit any overpayment, to our Deposit 
Account No. 50-0869 (File No. JGR 1004-1). 

Respectfully submitted, 



Dated: December 16, 2008 /Ernest J. Beffel. Jr./ 

Ernest J. Beffel, Jr., Reg. No. 43,489 
Attorney for Patent Owner 



HAYNES BEFFEL & WOLFELD LLP 

P.O. Box 366 

637 Main Street 

Half Moon Bay, CA 94019 

Telephone: 650.712.0340 

Facsimile: 650.712.0263 
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X. CLAIMS APPENDIX 

1 . (rejected) An interface for transactions among nodes in a network including a 
plurality of nodes which execute processes involved in the transactions, the interface 
being stored in a computer readable medium, comprising: 

a machine readable specification of an interface to transaction processes stored 
in memory accessible by at least one node in the network, including interpretation 
information providing a definition of an input document, and a definition of an output 
document, the definitions of the input and output documents comprising respective 
descriptions of sets of storage units and logical structures for the sets of storage units. 

2. (rejected) The interface of claim 1, wherein the interpretation information 
includes data type specifications for at least one logical structure in the definitions of the 
input and output documents. 

3. (rejected) The interface of claim 1, wherein the interpretation information 
includes at least one data structure mapping predefined sets of storage units for a 
particular logical structure in the definitions of the input and output documents, to 
respective entries in a list. 

4. (rejected) The interface of claim 1, including a repository in memory 
accessible by at least one node in the network storing a library of logical structures, and 
interpretation information for logic structures. 

5. (rejected) The interface of claim 1 , wherein the machine readable 
specification includes a document compliant with a definition of an interface document 
including logical structures for storing an identifier of a particular transaction, and at 
least one of definitions and references to definitions of input and output documents for 
the particular transaction. 

6. (rejected) The interface of claim 1 , wherein the machine readable 
specification includes a document compliant with a definition of an interface document 
including logical structures for storing an identifier of the interface, and for storing at 
least one of specifications and references to specifications of a set of one or more 
transactions supported by the interface. 

7. (rejected) The interface of claim 6, wherein the machine readable 
specification includes a reference to a specification of a particular transaction, and the 
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specification of the particular transaction includes a document including logical 
structures for storing at least one of definitions and references to definitions of input 
and output documents for the particular transaction. 

8. (rejected) The interface of claim 1 , wherein the storage units comprise 
parsed data. 

9. (rejected) The interface of claim 8, wherein the parsed data in at least one 
of the input and output documents comprises: 

character data encoding text characters in the one of the input and output 
documents, and 

markup data identifying sets of storage units according to the logical structure of 
the one of the input and output documents. 

1 0. (rejected) The interface of claim 9, wherein at least one of the sets of 
storage units encodes a plurality of text characters providing a natural language word. 

1 1 . (rejected) The interface of claim 8, wherein the interpretation information 
for at least one of the sets of storage units identified by a particular logical structure of at 
least one of the input and output documents, encodes respective definitions for sets of 
parsed characters. 

12. (rejected) The interface of claim 8, wherein the storage units comprise 
un parsed data. 

13. (rejected) The interface of claim 1 , including a repository stored in 
memory accessible by at least one node in the network of document types for use in a 
plurality of transactions, and wherein the definition of one of the input and output 
documents includes a reference to a document type in the repository. 

14. (rejected) The method of claim 1 3, wherein the repository of document 
types includes a document type for identifying participant processes in the network. 

1 5. (rejected) The interface of claim 1 , wherein the definitions of the input and 
output documents comprise document type definitions compliant with a standard 
Extensible Markup Language XML. 

16. (rejected) The interface of claim 1 , wherein the machine readable data 
structure including interpretation information comprises a document organized 
according to a document type definition compliant with a standard Extensible Markup 
Language XML. 

{ooi43569.doc } Page 38 



Application No. 09/173,858 



Atty Docket No.: OIN 1004-1 



17.-60. (cancelled). 

61 . (rejected) A method for programming a commercial transaction in a 
network, comprising: 

defining a machine readable definition of an input document for a node in the 
network including resources to execute a process in the transaction, and a machine 
readable definition of an output document for the node, the definitions of the input and 
output documents comprising respective descriptions of sets of storage units and logical 
structures for the sets of storage units; and 

providing interpretation information for the logical structures to the node. 

62. (rejected) The method of claim 61 , wherein the interpretation information 
includes data type specifications for at least one logical structure in the definitions of the 
input and output documents. 

63. (rejected) The method of claim 61 , wherein the interpretation information 
includes at least one data structure mapping predefined sets of storage units for a 
particular logical structure in the definitions of the input and output documents, to 
respective entries in a list. 

64. (rejected) The method of claim 61 , the step of providing interpretation 
information includes providing a repository in memory accessible by at least one node in 
the network storing a library of logical structures, and interpretation information for logic 
structures. 

65. (rejected) The method of claim 61, including defining a machine readable 
specification of an interface including a document compliant with a definition of an 
interface document including logical structures for storing an identifier of a particular 
transaction, and at least one of the definitions and references to the definitions of the 
input and output document. 

66. (rejected) The method of claim 61 , wherein the storage units comprise 
parsed data. 

67. (rejected) The method of claim 66, wherein the parsed data in at least 
one of the input and output documents comprises: 

character data encoding text characters in the one of the input and output 
documents, and 

{ooi43569.doc } Page 39 



Application No. 09/173,858 



Atty Docket No.: OIN 1004-1 



markup data identifying sets of storage units according to the logical structure of 
the one of the input and output documents. 

68. (rejected) The method of claim 67, wherein at least one of the sets of 
storage units encodes a plurality of text characters providing a natural language word. 

69. (rejected) The method of claim 67, wherein the interpretation information 
for at least one of the sets of storage units identified by a particular logical structure of at 
least one of the input and output documents, encodes respective definitions for sets of 
parsed characters. 

70. (rejected) The method of claim 66, wherein the storage units comprise 
unparsed data. 

71 . (rejected) The method of claim 61 , wherein the definitions of the input and 
output documents comprise document type definitions compliant with a standard 
Extensible Markup Language XML. 

72. (rejected) The method of claim 61, including: 

providing a parser to generate event signals in response to logical 

structures in the definition of the input document; and 

providing event listener programs which respond to the event signals to 
execute the process. 

73. (rejected) An interface for transactions among nodes in a network 
including a plurality of nodes which execute processes involved in the transactions, the 
interface being stored in a computer readable medium, comprising: 

a machine readable specification of an interface to an operation stored in 
memory accessible by at least one node in the network, including interpretation 
information providing a definition of an input document, and a definition of an 
output document, the definitions of the input and output documents comprising 
respective descriptions of sets of storage units and logical structures for the sets 
of storage units. 

74. (rejected) The interface of claim 73, wherein the interpretation information 
includes data type specifications for at least one logical structure in the definitions of the 
input and output documents. 
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